iT邦幫忙

2017 iT 邦幫忙鐵人賽
DAY 2
0
自我挑戰組

Framework 設計原則系列 第 2

怎樣才叫Well-Designed Framework

  • 分享至 

  • xImage
  •  

本文重點

  1. Framework Design Guideline 這本書到底再寫什麼內容?
  2. Framework Design Guideline 看完後預計會有什麼收獲?
  3. Well-Designed Framework

這本書到底再寫什麼內容?

話說為什麼會選這本書是因為推薦

但是這本書到底再寫些什麼內容,總不能30天後全部看完才知道吧

又不是推理小說來著的

就讓小的我來稍微簡介一下這本厚厚的原文書吧

30天後如果有人要二手購入的,歡迎內洽喔~

(到底要去哪裡內洽?????)

Guideline - 指導方針

顯然是.NET的一本教科書來著,內容包括

  1. 程式命名規則
  2. 各種Type的設計
  3. 什麼情況應該使用哪個Type
    Type就是包括Class,Interface,Emun那些我們會新增檔案的程式
    什麼時候要用Class,什麼時候要用Struct
    每個Type的說明與之間的差別
  4. Type裡的Member又該如何設計
    Member就是Type中的成員,包括property,Method...這些,you know
  5. Exceptions的設計方式
  6. 還有一些常用的元件要注意的地方

咦?這不是把第一天的東西又打了一次XD

看完後預計會有什麼收獲?

只要照著書中的Guidelines

就可以創造出一個前無古人後無來者驚天動地無所不能的Framework

是不可能的!!!/images/emoticon/emoticon07.gif

但是可以創造出一個設計良好容易閱讀方便擴充人見人愛的Framework/images/emoticon/emoticon34.gif

話說我連Framework都沒寫過

未來也沒有計畫開發

讀這個真的對目前的我有收穫嗎?

不用擔心,就算沒有那種天分寫出好的Framework造福大眾

http://ithelp.ithome.com.tw/upload/images/20161202/20091485u84bCrLAHh.jpg

我對自己的期許,希望讀完本書後至少能將下列應用到未來的工作上

  1. 建立自己的Coding standard,發現自己以往的錯誤
    像是不要用組織名稱來作為Namespace
  2. 常用元件在使用上的愚蠢錯誤
    像是不要宣告一個readonly的Array
  3. Type跟Member的選用取捨
  4. Exceptions的使用方式跟時機
  5. 增加英文閱讀能力

Well-Designed Framework

http://ithelp.ithome.com.tw/upload/images/20161202/20091485bLF8B5yrTA.png

Framework是我們每天都在使用的東西

好的Framework帶你上天堂,不好的Framework帶你住套房

相信大家都有過一邊Coding一邊幹譙的情況吧

『這甚麼鬼!!這麼難用!!』

『到底這個Method在寫些甚麼?』

『甚麼爛東西?為什麼沒有提供blablabla...功能』

"好" 這件事情其實很主觀的

『可以用來解決問題的就是好東西』

『沒有Bug就是好程式』

『需要全方面考量設計的完美計畫才能叫好』

每個人對於"好程式" "好設計" 的定義都不盡相同

http://ithelp.ithome.com.tw/upload/images/20161202/20091485QcckOXH35l.jpg

一般而言,想開發一個品質良好的Framework,至少得考量下列幾點

  • 簡單
  • 需要一直權衡取捨
  • 不要標新立異
  • 擴充性
  • 完整性
  • 一致性
  • 經得起考驗
  • 昂貴

接著就讓我們來各個擊破吧!!

簡單

『簡單好用』應該所有工程師在使用別人的套件時最希望遇到的事

很多厲害的傢伙常會迷思在我寫的東西多強大多完美

但寫出來的東西只有自己知道怎麼使用

這種慘品怎麼賣得出去

把功能簡化,按照各種情況獨立開發,不要一個大坨的

如果有更複雜的設計或邏輯,下一個版本再說吧

如何判斷這是個『簡單』的設計

使用『client-first programming』來測試自己的功能是否方便使用

這裡所謂的client指的就是我們工程師

也就是framework使用者,畢竟framework是開發給工程師用的

決定功能內容與input/output之後

找幾個工程師來問問

『如果有一個blablabla功能

你希望如何使用?

輸入甚麼?

回傳甚麼?』

如果大部分的人回答的內容跟你原先設計的不一樣

那就表示這個設計並不符合client的需求,再調整吧

需要一直權衡取捨

所以Framework需要甚麼功能,不要甚麼功能

要怎麼定義?怎麼實作?

都是需要Trade-Offs

要不斷經過討論調整

不要想要一個人躲起來想東想西的

出來聽聽聽大家的意見吧阿宅

不要標新立異

不要想要用甚麼創新的技術

盡量使用已經經過時間的淬鍊與多人的測試傳承下來的Design Pettern

百年老店,品質保證

不要隨便加入一個新的觀點

那會讓你的Framework增加失敗的機率

擴充性

這是為了『以防萬一』

雖然強調擴充性,但是為了不讓擴充功能搞壞了整個設計

記得把新的東西加在下一個版本

不要在目前版本放做了一半的半成品

畢竟『需要一直權衡取捨』(Trade-Offs)經過設計與討論之後才有變成產品的價值

完整性

這點我覺得有點太龐大

意思是指一個好的Framework必須能夠符合整個開發大環境

包括可以應用在不同的工具、程式語言與應用程式

目前為止有人做到全部嗎?

一致性

風格一致是一件很基本很重要卻好像很難做到的事

大家都討厭客戶變來變去的吧

但是其實我們也很常在變來變去

命名風格、設計風格、程式風格一致性

可以讓使用者更快速了解並上手

還記得上面說的『不要標新立異』嗎?

就讓你的Framework像iphone一樣,簡約、舒服

經得起考驗

除了Unit Test之外

還要把自己當作使用者來使用Framework

不是做完Unit Test就能宣稱是個tastable的Framework

站在使用者的立場面對自己開發的難用Framework吧

這時請擺脫『自己的小孩總是最可愛』的盲點

價值不斐

這一點應該是跟老闆說的

看完上面的論點之後

應該可以體會到一個好的Framework是需要大量的時間跟人力的

畢竟一分錢一分貨一枝草一點露

一個Alan一個月一個Framework

只想跟主管講

http://ithelp.ithome.com.tw/upload/images/20161202/20091485uyEd6lBkEZ.jpg

後繼

已無力...

昨晚看到半夜一點半導致失眠...

30天會不會撐不下去咱們明天見


上一篇
Framework Design Guidelines 讀書計畫
下一篇
設計Framework的基本原則
系列文
Framework 設計原則30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言